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(REVISED) APPEAL BRIEF 



Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Sir: 

In response to the Notification of Non-Compliant Appeal Brief dated 
April 5, 2007, the Applicant submits the following Revised Appeal Brief in 
accordance with the requirements of 37 C.F.R. § 41 .37(c). 

(1) REAL PARTY IN INTEREST 

The real party in interest is Telecommunication Systems, Inc. 



(2) RELATED APPEALS AND INTERFERENCES 

The Applicants and their legal representatives and assignee are not 
aware of any other appeals or interferences that will directly affect or be directly 
affected by or have a bearing on the Board's decision in the appending appeal. 
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(3) STATUS OF THE CLAIMS 

Claims 1-55 are pending in this application. Claims 1-55 stand 
rejected. Claims 1-55 are being appealed herein. 

(4) STATUS OF AMENDMENTS 

All amendments have been entered by the Examiner. The 

Applicants have not attempted to file any amendments to the claims after the 
Final Office Action dated March 17, 2006. A Request for Reconsideration filed 
by Applicants on May 16, 2006 was indicated by the Examiner as being entered. 

(5) SUMMARY OF THE CLAIMED SUBJECT MATTER 

Message routers conventionally simply route data from a source to 
a destination with no internal storage of information associated with data packets 
being routed. Conventionally, there is no convenient way of determining what 
devices are attached to a particular protocol gateway since message routers 
conventionally lack internal storage for information associated with routed data 
packets. 

Applicants' invention simplifies sending alerts to a plurality of 
stations attached to a particular protocol gateway by retrieving a station ID from 
customer information previously stored within a message router. The station ID 
is used to determine a communication type and the communication type is used 
to determine an associated protocol gateway. Thus, from a single data packet 
containing customer information, an alert can be sent to other station IDs 
attached to a particular protocol gateway. 

Applicants disclose a method and system, as recited by claims 1 
and 49, for sending an alert to selected client devices in a communications 
system including a server adapted to run a server application, a message router 
communicating with the server, a plurality of protocol gateways communicating 
with the message routers, and a network adapted to couple the server and the 
protocol gateways to client devices comprising generation of the alert with the 
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server application, the alert including customer information at, e.g., page 62, lines 
7-20. The alert is sent to the message router at, e.g., page 62, lines 17-20. A 
station ID of the client device is retrieved from the customer information 
previously stored within the message router at, e.g., page 63, lines 6-23. A 
communication type of the client device is determined based on the station ID at, 
e.g., page 63, line 12. One or more of the plurality of protocol gateways are 
selected based on the communication type at, e.g., page 63, lines 12-14. The 
alert is forwarded to the selected one or more of the plurality of protocol 
gateways at, e.g., page 63, lines 12-14. The alert is formatted with the protocol 
gateway for the selected client device at, e.g., page 12, line 11-page 13, line 6. 
The formatted alert is forwarded via the network to the selected client device at, 
e.g., page 63, lines 6-23. 

Applicants disclose a method and system, as recited by claims 23 
and 52, for sending alerts to client devices comprising generation of an alert at a 
server, the alert including a customer ID and a device ID at, e.g., page 62, lines 
7-20. The alert is forwarded to a message router at, e.g., 62, lines 17-20. The 
message router locates one or more station IDs from at least one of the customer 
ID and device ID previously stored within the message router at, e.g., page 63, 
lines 6-23. The message router determines a communication type associated 
with each station ID at, e.g., page 63, line 12. The alert is forwarded to a 
protocol gateway associated with the determined communication type at, e.g., 
page 63, lines 12-14. The protocol gateway transmits the alert over a network to 
the client devices at, e.g., page 63, lines 6-23. 

Applicants disclose a method and system, as recited by claims 37 
and 49, for sending an alert to selected client devices in a communications 
system comprising generation of an alert with a server application, the alert 
including customer information at, e.g., page 62, lines 7-20. A station ID of the 
client device is retrieved from the customer information previously stored within a 
message router at, e.g., page 63, lines 6-23. A communication type of the client 
device is determined based on the station ID at, e.g., page 63, line 12. One or 
more of a plurality of protocol gateways is selected based on a communication 
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type at, e.g., page 63, lines 12-14. The alert is forwarded to the selected one or 
more of the plurality of protocol gateways at, e.g., page 63, lines 12-14. The alert 
is formatted with the protocol gateway for the selected client device at, e.g., page 
12, line 11-page 13, line 6. 

(6) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

(A) Whether claims 1-6, 9, 12, 13, 23, 24, 29 and 36-53 are anticipated 
under 35 U.S.C. §1 02(e) by U.S. Patent No. 6,826,173 to Kung ("Kung"). 

(B) Whether claims 14-22 and 30-35 are obvious under 35 U.S.C. 
§1 03(a) over Kung in view of U.S. Patent No. 6,683,870 to Archer 
("Archer"). 

(C) Whether claims 7, 8, 25, 26, 43, 44, 54 and 55 are obvious under 
35 U.S.C. §1 02(e) over Kung in view of U.S. Patent No. 6,138,158 to 
Boyle et al. ("Boyle"). 

(D) Whether claims 10, 11, 27, 28, 46 and 47 are obvious under 35 
U.S.C. §1 02(e) over Kung in view of U.S. Patent No. 6,507,589 to 
Ramasubramani et al. ("Ramasubramani"). 

(7) ARGUMENT 

(A) Claims 1-6. 9. 12. 13. 23. 24. 29 and 36-53 are not 
anticipated under 35 U.S.C. § 102(e) bv Kung. 

All rejected system and method claims 1-6, 9, 12, 13, 23, 24, 29 
and 36-53 require any of customer information, customer ID and device ID to be 
stored within a message router . 

The Examiner ACKNOWLEDGED in the Office Action dated March 
17, 2006 that Kung allegedly discloses "preference data is the user specified 
information detailing where the user wants the call to do, and the terminal 
configuration data is information about the devices connected to the broadband 
residential gateway and specify which device can receive which type of call, and 
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Column 13, lines 15-24, where the preference data is stored previously on a 
database obtained easy by the router (Call manager)". 

Thus, the Examiner acknowledged that Kung allegedly discloses 
preference data that is previously stored in a call manager is easily obtained by 
a router. The Examiner appears to be equating a Kung's router and Kung's call 
manager. However, Kung's router and call manager are two distinct elements 
within Kung's network, i.e., router is disclosed as item 210 and call manager is 
disclosed as item 218, with nothing within Kung disclosing router 210 has any 
capability to store any type of information. Thus, the Examiner 
ACKNOWLEDGED that Kung discloses preference data stored within a call 
manager NOT stored within a router much less disclose customer information, 
customer ID and device ID stored within a message router , as recited by claims 
1-6, 9, 12, 13, 23, 24, 29 and 36-53. 

Moreover, Kung at col. 13, lines 15-24 is a small portion of a 
paragraph that begins at col. 13, line 9. Kung's paragraph beginning at col. 13, 
line 9 describes various types of information that are stored in databases within 
call manager 218. Kung at col. 13, lines 15-24 fails to address features 
associated with a router 210. 

The Advisory Action dated June 5, 2006 further compounds 
Applicants' frustration. The Examiner alleged Kung that discloses "the station ID 
and customer configuration information was stored on a router, wherein the 
information is stored in the IP central station (Fig. 1, element 200) where the 
central station includes a call manager (Figure 2, element 218) this call manager 
is part of the central station and contains all the preference information and 
station ID (Column 7, lines 62-67 and Column 13, lines 15-24) as part of the 
router and the information is stored in a database within the router." 

The Advisory Action dated June 5, 2006 alleges that the station ID 
and customer configuration information was stored on a router, wherein the 
information is stored in the IP central station. Nothing within Kung supports 
router 210 performs ANY type of storage . Thus, the Examiner cannot assume 
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Kung's router 210 is performing anything other than conventional routing of data 
packets within a network. 

Moreover, Kung's central station is disclosed as item 200. 
However, also part of the central station 200 is the Internet 180 and a Public 
Switched Telephone Network 160. Thus, central station 200 is NOT a single 
device that includes a router but a plurality of devices that are interconnected. 
As discussed above, Kung's router and call manager are two distinct elements 
within Kung's network, i.e., router is disclosed as item 210 and call manager is 
disclosed as item 218, with nothing within Kung disclosing router 210 has any 
capability to store any type of information. Thus, Kung fails to disclose or 
suggest any of customer information, customer ID and device ID t o be stored 
within a message router , as recited by claims 1-6, 9, 12, 13, 23, 24, 29 and 36- 
53. 

Moreover, all rejected system and method claims 1-6, 9, 12, 13, 23, 
24, 29 and 36-53 require retrieving a station ID of a client device from any of 
customer information, customer ID and device ID previously stored within a 
message router . 

Moreover, even if Kung disclosed preference data stored within a 
router, which the Examiner acknowledged that Kung fails to do in the Office 
Action dated March 17, 2006, a thorough reading of Kung appears to verify the 
Examiner's allegation that Kung's preference data details "where the user wants 
the call to do, and the terminal configuration data is information about the devices 
connected to the broadband residential gateway and specify which device can 
receive which type of call". Thus, Kung fails to disclose retrieving a station ID of 
a client device FROM another type of information , much less retrieving a station 
ID of a client device FROM another type of information previously stored within a 
message router , much less disclose a system and method of retrieving a station 
]D of a client device FROM any of customer information, customer ID and device 
ID previously stored within a message router , as recited by claims 1-6, 9, 12, 
13, 23, 24,29 and 36-53. 
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A benefit of retrieving a station ID of a client device from any of 
customer information, customer ID and device ID previously stored within a 
message router is, e.g., providing an alert to more stations. In many instances, 
an alert service may want to send an alert to stations without knowing all of the 
station IDs of stations and their associated station IDs attached to a network. 
Conventionally, alerts are only able to be sent to stations with station ID known in 
advance . However, an alert source may want to target additional stations. By 
retrieving a station ID of a client device from any of customer information, 
customer ID and device ID previously stored within a message router , an alert 
can be sent to stations without knowing in advance station IDs. The cited prior 
art fails to disclose or suggest the claimed features having such benefits. 

Hence, the rejection should be withdrawn because it fails to 
demonstrate that the applied reference discloses each and every element of the 
claim , as discussed above. See MPEP 2131. "The identical invention must be 
shown in as complete detail as is contained in the ... claim." Richardson v. Suzuki 
Motor Co. , 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
"Anticipation cannot be predicated on teachings in the reference which are vague 
or based on conjecture." Studienqesellschaft Kohle mbH v. Dart Industries, Inc. , 
549 F. Supp. 716, 216 USPQ 381 (D. Del. 1982), affd. . 726 F.2d 724, 220 USPQ 
841 (Fed. Cir. 1984). 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
Kung does not anticipate any of claims 1-6, 9, 12, 13, 23, 24, 29 and 36-53. 
Thus, the rejection of claims 1-6, 9, 12, 13, 23, 24, 29 and 36-53 under 35 U.S.C. 
§ 102(e) is improper and should be reversed. 

(B) Claims 14-22 and 30-35 are not obvious under 35 U.S.C. 
§1 03(a) over Kung in view of Archer. 

All rejected system and method claims 14-22 and 30-35 require 
retrieving a station ID of a client device from any of customer information, 
customer ID and device ID previously stored within a message router . 
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Archer is relied on to disclose sending a message to a device that 
is considered active and to send a message to all device that a subscriber has in 
his account (See Office Action dated March 17, 2006, page 7). 

Thus, Kung modified by the disclosure of Archer would STILL fail to 
disclose or suggest a system and method of retrieving a station ID of a client 
device from another type of information , much less retrieving a station ID of a 
client device from any of customer information, customer ID and device ID 
previously stored within a message router as recited by claims 14-22 and 30- 
35. 

Moreover, Claims 14-20 and 31-35 recite a system and method 
relying on a device ID that can be set to all devices. 

The Office Action dated March 17, 2006 acknowledged that Kung 
fails to disclose an alert that includes an active device only flag and a device ID 
set to all devices (See Office Action dated March 17, 2006, page 7). The Office 
Action dated March 17, 2006 relied on Archer to allegedly make up for the 
deficiencies in Kung to arrive at the claimed features. The Applicants respectfully 
disagree. 

The Examiner ACKNOWLEDGED that Archer discloses sending a 
message to all devices that a subscriber has added to his account. Thus, the 
Examiner ACKNOWLEDGED that Archer simply discloses sending a message to 
all devices specified within an account NOT setting any type of device ID to all 
devices, as recited by claims 14-20 and 31-35. 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
Kung in view of Archer does not render obvious any of claims 14-20 and 31-35. 
Thus, the rejection of claims 14-20 and 31-35 under 35 U.S.C. § 103(a) is 
improper and should be reversed. 
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(C) Claims 7. 8, 25, 26, 43, 44, 54 and 55 are not obvious under 
35 U.S.C. §1 03(a) over Kung in view of Boyle. 

All rejected system and method claims 7, 8, 25, 26, 43, 44, 54 and 
55 require retrieving a station ID of a client device from any of customer 
information, customer ID and device ID previously stored within a message 
router . 

The Examiner relies on Boyle to allegedly make up for the 
deficiencies in Kung to arrive at the claimed features. The Applicants respectfully 
disagree. 

The Office Action dated March 17, 2006 acknowledged that Kung 
fails to disclose segmenting an alert with a selected protocol gateway into 
message segments before sending the alert over a network and having the client 
reconstruct the message segments (See Office Action dated March 17, 2006, 
page 11). The Office Action dated March 17, 2006 relied on Boyle at col. 13, 
lines 37-48 to allegedly make up for the deficiencies in Kung to arrive at the 
claimed features. The Applicants respectfully disagree. 

Boyle discloses at col. 13, lines 37-48 segmenting a PUSH PDU 
into a sequence of fragments, each being treated as a short message with a 
length no more than the maximum length allowed in a SMSC. However, Boyle, 
like Kung, fails to disclose or suggest retrieving of a station ID from another type 
of information , much less disclose or suggest retrieving a station ID from any of 
customer information, customer ID and device ID . much less retrieving a station 
ID of a client device from any of customer information, customer ID and device ID 
previously stored within a message router , as recited by claims 7, 8, 25, 26, 43, 
44, 54 and 55. 

Thus, Kung theoretically modified by the disclosure of Boyle would 
STILL fail to disclose or suggest retrieving a station ID of a client device from any 
of customer information, customer ID and device ID previously stored within a 
message router , as recited by claims 7, 8, 25, 26, 43, 44, 54 and 55. 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
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Kung in view of Boyle does not render obvious any of claims 7, 8 f 25, 26, 43, 44, 
54 and 55. Thus, the rejection of claims 7, 8, 25, 26, 43, 44, 54 and 55 under 35 
U.S.C. § 103(a) is improper and should be reversed. 

(D) Claims 10, 11. 27, 28, 46 and 47 are obvious under 35 
U.S.C. §1 03(a) over Kung in view of Ramasubramani. 

All rejected system and method claims 10, 11, 27, 28, 46 and 47 
require retrieving a station ID of a client device from any of customer information, 
customer ID and device ID previously stored within a message router . 

The Office Action dated March 17, 2006 acknowledged that Kung 
fails to disclose returning an acknowledgement from a client to a protocol 
gateway and then forwarded to a server (See Office Action dated March 17, 
2006, page 11). The Office Action dated March 17, 2006 relied on 
Ramasubramani at col. 8, lines 20-35 to allegedly make up for the deficiencies in 
Kung to arrive at the claimed features. The Applicants respectfully disagree. 

Ramasubramani at col. 8, lines 20-35 discloses an Internet receive 
process and a deliver process, the deliver process waiting for an 
acknowledgement that a notification was received and may also retry the sending 
as needed. However, Ramasubramani, like Kung and Boyle, fails to disclose or 
suggest retrieving of a station ID from another type of information , much less 
disclose or suggest retrieving a station ID of a client device from any of customer 
information, customer ID and device ID previously stored within a message 
router , as recited by claims 10, 1 1 , 27, 28, 46 and 47. 

Thus, Kung modified by the disclosure of Ramasubramani would 
STILL fail to disclose or suggest retrieving a station ID of a client device from any 
of customer information, customer ID and device ID previously stored within a 
message router , as recited by claims 10, 1 1 , 27, 28, 46 and 47. 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
Kung in view of Ramasubramani does not render obvious any of claims 10, 11, 
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27, 28, 46 and 47. Thus, the rejection of claims 10, 1 1, 27, 28, 46 and 47 under 
35 U.S.C. § 103(a) is improper and should be reversed. 



For all the reasons set forth above, the rejections of claims 1-55 are 
improper and should be reversed. The Applicants therefore respectfully request 
that this Appeal be granted and that the rejections of the claims be reversed. 

Respectfully submitted, 



MANELLI DENISON & SELTER PLLC 

2000 M Street, N.W. 7th Floor 

Washington D.C. 20036-3307 

Tel. (202)261-1020 

Fax. (202) 887-0336 

WHB/df 



CONCLUSION 
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APPENDIX 
CLAIMS INVOLVED IN THE APPEAL 

1. (previously presented) A method of sending an alert to 
selected client devices in a communications system including a server adapted to 
run a server application, a message router communicating with the server, a 
plurality of protocol gateways communicating with the message routers, and a 
network adapted to couple the server and the protocol gateways to client 
devices, comprising: 

generating said alert with said server application, said alert 
including customer information; 

sending said alert to said message router; 

retrieving a station ID of said client device from said customer 
information previously stored within said message router; 

determining a communication type of said client device based on 
said station ID; 

selecting one or more of said plurality of protocol gateways based 
on said communication type; and 

forwarding said alert to said selected one or more of said plurality of 
protocol gateways; 

formatting said alert with said protocol gateway for said selected 
client device; and 

forwarding said formatted alert via said network to said selected 

client device. 

2. (previously presented) The method of claim 1 , wherein: 
said customer information includes at least one of a customer ID 

and a port number. 
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3. (previously presented) The method of claim 2 X wherein: 

said step of determining a communication type further comprises 
searching a user table to obtain said station ID associated with said customer ID. 

4. (previously presented) The method of claim 2, wherein: 

said step of determining a communication type further comprises 
searching a local cache of said message router for said station ID associated 
with said customer ID. 

5. (previously presented) The method of claim 2, wherein: 

said step of determining a communication type further comprises 
searching a local cache of said message router and a device table for a first 
device associated with said customer ID when both said customer ID and port 
number are provided. 

6. (previously presented) The method of claim 1, further 

comprising: 

returning an inactive customer message to said server if no station 
ID is retrieved. 

7. (previously presented) The method of claim 1, further 

comprising: 

segmenting said alert with said selected protocol gateway into 
message segments before sending said alert over said network. 

8. (previously presented) The method of claim 7, further 

comprising: 

assembling said message segments at said client device. 
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9. (previously presented) The method of claim 1 , wherein: 

said alert includes at least one of an alert message, a compression 
flag, an encryption flag, and an acknowledgement flag. 

10. (previously presented) The method of claim 1, further 

comprising: 

returning an acknowledgement to said selected protocol gateway 
after receiving said formatted alert message at said client device. 

11. (previously presented) The method of claim 10, further 

comprising: 

forwarding said acknowledgement from said selected protocol 
gateway to said server. 

12. (previously presented) The method of claim 1 , wherein: 
said customer information is a client information object. 

13. (previously presented) The method of claim 12, wherein: 
said client information object includes a customer ID and a device 

ID. 

14. (previously presented) The method of claim 13, wherein: 
said alert includes an active device only flag and wherein said 

device ID can be set to all devices. 

15. (previously presented) The method of claim 14, further 

comprising: 

searching a local cache of said message router for said station ID if 
said active device only flag is set and said device ID is specified. 
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16. (previously presented) The method of claim 15, further 

comprising^ 

searching a user table for said station ID if said station ID is not 
located in said local cache. 

17. (previously presented) The method of claim 14, further 

comprising: 

searching only said user table for active client devices associated 
with said customer ID if said active device only flag is set and said device ID is 
set to all devices. 

18. (previously presented) The method of claim 14, further 

comprising: 

searching a local cache of said message router for said station ID if 
said active device only flag is not set and said device ID is specified. 

19. (previously presented) The method of claim 18, further 

comprising: 

searching a device table for said station ID if said station ID is not 
located in said local cache. 

20. (previously presented) The method of claim 14, further 

comprising: 

searching a device table for client devices associated with said 
customer ID if said active only flag is not set and said device ID is set to all 
devices. 

21. (previously presented) The method of claim 1, further 

comprising: 

providing each station ID retrieved in said step of retrieving a 
station ID to said server. 
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22. (previously presented) The method of claim 1, further 

comprising: 

providing each station ID retrieved by said message router to said 
server, before forwarding said alert to said protocol gateway. 

23. (previously presented) A method of sending alerts to client 
devices, comprising: 

generating said alert at a server, said alert including a customer ID 
and a device ID; 

forwarding said alert to a message router; 

locating with said message router one or more station IDs from at 
least one of said customer ID and device ID previously stored within said 
message router; 

determining with said message router a communication type 
associated with each station ID; 

forwarding said alert to a protocol gateway associated with said 
determined communication type; and 

transmitting said alert with said protocol gateway over a network to 
said client devices. 

24. (previously presented) The method of claim 23, further 

comprising: 

receiving said alert with a transport layer of an application running 
on said protocol gateway and sending said alert from said transport layer to client 
applications. 

25. (previously presented) The method of claim 24, further 

comprising: 

segmenting said alert into message segments with said protocol 

gateway. 
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26. (previously presented) The method of claim 25, wherein: 
said client application assembles said message segments. 

27. (previously presented) The method of claim 23, further 

comprising: 

sending an acknowledgement from said client device to said 
protocol gateway once said alert is received by said client device. 

28. (previously presented) The method of claim 27, further 

comprising: 

sending said acknowledgement from said protocol gateway to said 
server that forwarded said alert after receiving said acknowledgement from said 
client device. 

29. (previously presented) The method of claim 23, wherein: 
said alert comprises at least one of an alert message, a client 

information object including said customer ID and device ID, message flags, 
compression flag and an encryption flag. 

30. (previously presented) The method of claim 29, wherein said 
messages flags specify at least one of: 

whether said server requires an acknowledgement message; 

whether said alert should be sent only if said client device is 
currently active; and 

whether said protocol gateway should only attempt message 
delivery once. 

31 . (previously presented) The method of claim 23, wherein: 
said alert includes an active device only flag and said device ID can 

be set to all devices. 
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32. (previously presented) The method of claim 31 , wherein said 
locating step comprises: 

searching a local cache of said message router for said station ID if 
said active device only flag is set and said device ID is specified; 

searching only a user table for active client devices associated with 
said customer ID if said active device flag is set and said device ID is set to all 
devices; 

searching a local cache of said message router for said station ID if 
said active device only flag is not set and said device ID is specified; and 

searching a device table for client devices associated with said 
customer ID if said active device only flag is not set and said device ID is set to 
all devices. 

33. (previously presented) The method of claim 32, further 

comprising: 

for said steps of searching a local cache of said message router, 
searching a database for said station ID if said station ID is not found in said local 
cache. 

34. (previously presented) The method of claim 31, further 

comprising: 

providing each device ID located to server if device ID is set to all 

devices. 

35. (previously presented) The method of claim 31, further 

comprising: 

sending an inactive message to said server if no device is located 
and said device ID is set to all devices, otherwise sending a customer not valid 
message. 
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36. (previously presented) The method of claim 23, further 

comprising: 

formatting said alert for said client device with said protocol 

gateway. 

37. (previously presented) A method of sending an alert to 
selected client devices in a communications system, comprising: 

generating said alert with a server application, said alert including 
customer information; 

retrieving a station ID of said client device from said customer 
information previously stored within a message router; 

determining a communication type of said client device based on 
said station ID; 

selecting one or more of a plurality of protocol gateways based on a 
communication type; and 

forwarding said alert to said selected one or more of said plurality of 
protocol gateways; and 

formatting said alert with said protocol gateway for said selected 

client device. 



38. (previously presented) The method of claim 37, wherein: 
said customer information includes at least one of a customer ID 
and a port number. 



39. (previously presented) The method of claim 38, wherein: 
said step of determining a communication type further comprises 
searching a user table to obtain said station ID associated with said customer ID. 
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40. (previously presented) The method of claim 38, wherein: 
said step of determining a communication type further comprises 

searching a local cache of a message router for said station ID associated with 
said customer ID. 

41 . (previously presented) The method of claim 36, wherein: 
said step of determining a communication type further comprises 

searching a local cache of a message router and a device table for a first device 
associated with said customer ID when both said customer ID and port number 
are provided. 

42. (previously presented) The method of claim 37, further 

comprising: 

returning an inactive customer message to said server if no station 
ID is retrieved. 

43. (previously presented) The method of claim 37, further 

comprising: 

segmenting said alert with said selected protocol gateway into 
message segments before sending said alert over said communications system. 

44. (previously presented) The method of claim 43, further 

comprising: 

assembling said message segments at said client device. 

45. (previously presented) The method of claim 37, wherein: 
said alert includes at least one of an alert message, a compression 

flag, an encryption flag, and an acknowledgement flag. 
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46. (previously presented) The method of claim 37, further 

comprising: 

returning an acknowledgement to said selected protocol gateway 
after receiving said formatted alert message at said client device. 

47. (previously presented) The method of claim 46, further 

comprising: 

forwarding said acknowledgement from said selected protocol 
gateway to said server. 



48. (previously presented) The method of claim 37, wherein: 
said customer information is a client information object. 

49. (previously presented) A system for sending an alert to 
selected client devices in a communications system, comprising: 

means for generating said alert with a server application, said alert 
including customer information; 

means for retrieving a station ID of said client device from said 
customer information previously stored within a message router; 

means for determining a communication type of said client device 
based on said station ID; 

means for selecting one or more of a plurality of protocol gateways 
based on a communication type; and 

means for forwarding said alert to said selected one or more of said 
plurality of protocol gateways; and 

means for formatting said alert with said protocol gateway for. said 
selected client device. 
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50. (previously presented) The system for sending an alert to 
selected client devices in a communications system according to claim 49, 
wherein: 

said customer information includes at least one of a customer ID 
and a port number. 

51. (previously presented) The system for sending an alert to 
selected client devices in a communications system according to claim 50, 
wherein: 

said means for determining a communication type comprises a 
means for searching a user table to obtain said station ID associated with said 
customer ID. 

52. (previously presented) A system for sending alerts to client 
devices, comprising: 

means for generating said alert at a server, said alert including a 
customer ID and a device ID; 

means for forwarding said alert to a message router; 

means for locating with said message router one or more station 
IDs from at least on of said customer ID and device ID previously stored within 
said message router; 

means for determining with said message router a communication 
type associated with each station ID; 

means for forwarding said alert to a protocol gateway associated 
with said determined communication type; and 

means for transmitting said alert with said protocol gateway over a 
network to said client devices. 
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53. (previously presented) The system for sending alerts to 
client devices according to claim 52, further comprising: 

means for receiving said alert with a transport layer of an 
application running on said protocol gateway and sending said alert from said 
transport layer to client applications. 



54. (previously presented) The system for sending alerts to 
client devices according to claim 53, further comprising: 

means for segmenting said alert into message segments with said 
protocol gateway. 

55. (previously presented) The method of claim 54, wherein: 
said client application assembles said message segments. 
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